[レポート]どのアジャイル開発チームでも起こりえる課題を事例を通して学ぼう! #scrumosaka
Scrum Fest Osakaとは?
2020年6月26(金)・27日(土)にScrum Fest Osakaがオンラインで開催されました。 Scrum Fest Osaka 2020@ONLINEは以下のようなイベントです。クラスメソッドではシルバースポンサーとして協賛を行いました。
Scrum Fest Osakaはスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。この2日間を通じ、参加社同士でスクラムやアジャイルプラクティスについての知識やパッションをシェアするだけでなく、ここで出会ったエキスパートに困りごとを相談することもできます。
どのアジャイル開発チームでも起こりえる課題を事例を通して学ぼう!
本記事は、セッション「どのアジャイル開発チームでも起こりえる課題を事例を通して学ぼう!」をレポートします。
スピーカー
Etsuo Yamada(Red Hat K.K.)
Takahiro Hisasue(Red Hat K.K.)
セッション概要
「アジャイル開発の事例を聞いたけど、いざ自分ごとで考えるよく分からない…」 「このエピソードは、どこでも起きうる話なのだろうか?」 「自分の現場で起きている課題は、どのチームにも起こり得る課題なのだろうか?」
事例だけ聞いても分からない…一方で抽象化した理論だけ聞いてもよくわからない…みたいなこと、ありませんか?
今、現場で起きている課題の先に光があるのだろうか?そんなふうに心配している方々に進む勇気を持って頂ければという思いで話させて頂きます。
レポート
アジャイルチームの成長に伴い起きる変化について
スクラムチームがはじめてできた時、チームメンバーだけでなくマネージャー・経営者などが開発チームに対して不安や心配になることがあります。チームメンバーも自分たちが成長できているか、壁にぶつかった時の判断が正しいのかと不安に。このようなスクラムチームが成長する過程での「あるある」を紹介。
チームの成長
はじめてのアジャイル開発で起こりがちなチーム支援の構図
- 自分から動かないメンバーばかりだから指示を出してあげなさい!
- 最初のスプリントからうまくできないと続けさせないよ!
- 失敗チームで信用ならんので支援しよう!
- ダメならいろんなツールや進め方などどんどん取り入れれば良いじゃないかい!
などを、エラい人が言ったり聞いたりするケースがある。その場合の多くは、それまでの過程を知らないことが多いです。当初思っていたイメージとのギャップがあり、いきなりチームがトップギアーに入ることを想像していたのでしょう。チームの変化の過程を理解する必要があります。
タックマンモデル+1
チームの変化をタックマンモデルで説明できます。(教育 → 形成期 → 混乱期 → 統一期 → 機能期)
第1段階(教育 → 形成期 → 混乱期)
スクラムの基本からアジャイルマインドセットを理解するフェーズ
- 基礎知識の教育を受けて、アジャイル開発に慣れていく段階
- 3〜5スプリントくらいまでがおおよその目安
- アジャイル開発の基礎知識が経験によって強化され、理解度が向上
- 反復的な開発を通して、基本的な進め方を理解
- 小さく失敗して、大きく活かすことの意義を体で理解していく
この段階でよくあるチームの状況
チームメンバー同士が「◯◯だと思っていた」など勝手な思い込みや、疑問があっても声に出さないなどで誤解が生じる。チームの行動がばらばら。
第2段階(混乱期→ 統一期)
各役割で効果的な動きができるようになっていくフェーズ
- アジャイル開発の進め方に慣れ、自律的なチーム運営をし始める段階
- 3〜7スプリントくらいがおおよその目安
- メンバーがそれぞれの役割を理解し、効果的に振舞うようになる
- 1回のスプリントでチームが要件を消化するベロシティが安定
この段階でよくあるチームの状況
スプリントレビューでフィードバックに対してい開発チームがネガティブな気持ちをもつ。表面的な課題の洗い出しに満足し、本質的な問題までたどり着かない。
題3段階(統一期 → 機能期)
自身の役割をこえて、相互に支援できるようになっていくフェーズ
- 自律的なチームになり、積極的なチャレンジをするようになる段階
- 5〜10スプリントくらいがおおよその目安
- メンバーがそれぞれの役割を理解し、他メンバーのサポートに積極的
- フィードバックから気づきを得て、勝手にどんどん成長していく
この段階でよくあるチームの状況
スクラムマスターが交通整理しなくてもメンバー同士で改善作業が進む。チームの能力が成長したことでPOからのストーリー供給が追いつかない。
チーム成長のまとめ
スクラム開発の全体をとおしてチームに起きる変化
- フィードバックによる業務知識の蓄積とプロダクト改善
- 振り返りによるチームの継続的なプロセス改善
- 見える化によるチームの情報共有
- スキルトランスファーによる個々のスキル、全体の作業効率の向上
- ツールなどの環境面の効率化 etc.
組織のおさえるべき問い
アジャイル開発を進める際に、「アジャイル開発はうちの会社(組織)に合うのか?」「うちは特殊だから...」という声を多くきく。既存の手法が計画重視に最適化されてるので、違いがあって当たり前なのです。フォーターフォールとアジャイルに着目して課題解決しようとすると本来の目的を見失ってしまうことがあります。
フォーターフォールトアジャイルの違いを対処するのも大事ではありますが、「アジャイル開発を取り込むことで何を求めているのか?」が大切です。
- アジャイルがもたらす「どんな効果を期待するのか」を考え、その良さを引き出すためにどう課題を解決していくのか考える
- ただし期待効果は試してみないと検証はできない
- 経験を積み重ねる中で、アジャイルな組織文化が形成される
まとめ
「どのアジャイル開発チームでも起こりえる課題」というタイトル。今まで参加してきたスクラム開発を振り返ると、まさに「あるある」でした。開発初期(1〜3スプリント)は特に、もやもやしたり進め方に疑問が出てきたりすることが多くあります。しっかりとお客様・OP、スクラムマスター&開発チームと向き合い、成長の過程を理解して取り組むことが大事だとあらためて認識しました。
自律的なチームを作るのは、簡単ではありませんがそこでしか得られない価値も多くあると実感します。